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NASA-ARC continues a history of manifesting cost 
efficient (< $250M) , increasingly-capable Small Satellites 
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cost efficient, increasingly-capable CubeSats | 


Rationale for Testing 


The GlobalStar network is a constellation of satellites in LEO for satellite phones and 
low speed data communications. . 


It could be a low cost, low SWaP w 
option for cubesat communications 4s 


} Active Antenna 


The simplex unit, STX3, seems 
to be a good option forevery ‘4 | 
cubesat to have a beacon if cme 


USB-2CM-BB Fsw sim 
Cape BBB BBB 


We were testing the duplex 
unit, the GSP-1720, for 
feasibility for the Pathfinder 
Technology Demonstrator 
Project 


GlobalStar Satellite Data/Volice Module 
GSP-1720 


Key Questions 


1. Can it survive the space environment? 


2. What is the quality of the communication service? 


1. What do we mean by quality of service? 


1. 


2. 


Data Rate/Throughput — what can we expect it to be? 
How often are we going to get dropped? 
What does it take to re-establish the link? Does it come back on easily? 


How does it interact with normal spacecraft configuration? 
1. Interactions w/ BeagleBone Black and our FSW 


Overview of Testing 


-Vibration testing 


-TVAC testing 
-4 hot and cold cycles 
-1 hot survival turn on 
-1 cold survival turn on 


-Performance Testing 
-Flatsat setup 
-iPerf 
-ftp 
-ITOS 


GSP-1720 Duplex Modem Board 


Vibration Testing 


The Globalstar radio (GSP-1720) was subjected to random vibration equivalent to the 


GEVS qual test levels (14.2grms) using the vibration test facility in the Ames 
Engineering Evaluation Lab 2 


The test timeline consisted of the 
following major elements: 


-Pre-vibe functional test 
-Mounting of the GSP-1720 to the 
vibration facility 

-Performance of the test 
-Post-vibe functional test ae 


-The GSP-1720 successfully a freee 
turned on, communicated with the — | /— 
GlobalStar network, and ed 
transferred data after the vibration 
test 


Vibe Profile 


Thermal Vacuum Testing 


The Globalstar radio (GSP-1720) was subjected to thermal vacuum testing using the 
small TVAC chamber in the Engineering Evaluation Lab (EEL) at Ames Research Center. 


GSP-1720 in EEL TVAC Chamber 


The test timeline consisted of the \ 
following major elements: 

-4 thermal cycles 

-8 proto-qualification plateaus for 
electrical performance testing of the 


component a ae 

-8 transitions —. on 
-One cold and one hot survival GlobalStar Temperature (deg C) vs. Time (days) 
plateau for survival turn-on 100 


-The GSP-1720 successfully 
turned on, communicated with the 
GlobalStar network, and 
transferred data during each 
plateau and after the cycling was 
complete Time (days) 


Temperature (deg C) 
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Disconnected 


¢ System consists of four state 


* Connected Eoemecres 
¢« Disconnected en 

¢ Calling 

¢ No Answer (Wait) \. 


¢ Connected times (“pass”) 
varied from 5-18 minutes Connection Time 
(25%-75%) sof | 


¢ Reconnection took from 30 = 
seconds to several minutes ™ 


Characterization of System Jitter 


Test performed using UDP. este yn cr eee ee 
¢ Connected a se 
¢ Disconnected 

¢ Calling 

¢ No Answer (Wait) 

Jitter 

¢ Jitter increases w/packet size 

* Downlink worse than uplink escent oe . 


e Jitter generally < 1 sec 


¢ Packet Loss 
e Individual packet loss 10- 30% | 7 

for UDP (no retransmission) 
¢ Downlink worse than uplink 


Data Rates Using TCP/IP 


¢ Uplink and downlink data rates between spacecraft and ground system characterized 
over several days 
¢ Data rate reduced by 20% due to overhead (8 kbps vs. 9.6 kbps capability) 
¢ Some reduction in performance for: 
¢ Smaller packet sizes 
¢ Arbitrarily constrained TCP window size 
¢ Disabling Nagle processing 


D TCP Download Bandwidth by Packet and TCP Window Size 
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¢ Ground/FSW interactions characterized using full system — spacecraft, 
GlobalStar & ground system running ITOS 
¢ Telemetry latency bounds calculated using timestamped events in data 
stream 
¢ Command execution 
¢ Receipt of data 
¢ Resumption of operations after waiting for housekeeping 
¢ Command links established 108 times over several days 
¢ Latency measured at between two and eight seconds 
¢ Six transfer failures logged by the system 
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¢ GlobalStar GSP-1720 modem passed vibration and TVAC tests to GEVS levels 
¢ Modem successfully integrated with existing NASA flight software and ground 
system 
¢ LADEE flight software running on BeagleBone Black with cFS/cFE stack 
¢ ITOS ground software suite running on LINUX box 
¢ Performance of overall system characterized 
¢ Successfully ran UDP, PPP, FTP and TCP/IP protocols 
¢ Jitter and throughput reasonably close to expected capability of system 
¢ Larger packet size transfers were more efficient 
¢ Loss of signal was handled autonomously, although the time for reconnection 
varied 
¢ Simultaneous uplink and downlink did not affect overall performance 
¢ Demonstrated CFDP — CCSDS File Delivery Protocol 
¢ Further characterization required on-orbit 
¢ Ground tests did not include GlobalStar spacecraft or Ground Station hand offs 
¢ Re-acquisition time will depend on relative positions of spacecraft and 
GlobalStar constellation 


Questions? 
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-Still need to fully analyze the results and collate into presentations, papers, etc 


-What should we focus on, what would be most useful to SSTP? 
-Do we want to analyze the ITOS data? 
-What kind of results are we looking for? 


-Questions to GlobalStar 
-making it smaller? 
-Business case? Are they ready/accommodating? 


-Data throughput 
-Is it worth, an 8k file, how long would it take, can we do it all day? 
-Ground implementation? 
-Connection time, deviation, min/max 
-Include unknowns and concerns 


-PTD data volume requirement: 250 Mbits per day 


-current PTD command requirement: “near real time” — a few seconds 


Performance Testing 


The Globalstar radio (GSP-1720) was subjected to performance testing using a setup 
in the trailers near Building N269, and some limited testing in the N213 Penthouse. 


-iPerf testing 
-iPerf3 is a tool for active measurements of the maximum achievable 
bandwidth on IP networks. The test requires running a server on an Internet accessible 
workstation with static IP and a client on the GlobalStar modem host. The necessary 
test scripts and result processing scripts can be found in the PPF Git repository. 


https ://babelfish.arc.nasa.gov/confluence/display/PPFFSW/iPerf3+Tests+for+GlobalStar+Modem 
-ftp testing 

-The File Transfer Protocol (FTP) is a standard network protocol used to transfer files 

from one host to another host over a TCP-based network. The purpose of this test is see 

whether FTP file transfer is a good candidate for the GlobalStar network. For this test 

the FTP server is configured on the GlobalStar modem host (BeagleBone Black). The 

script is written to automatically upload, download and then delete 4 files (1KB, 10KB, 

100KB and 1MB) with random content to the FTP server. The script will also 

restart/continue the FTP transfer if it fails. The ftp_test_parser.py script extracts and 

process the log file output. 

https ://babelfish.arc.nasa.gov/confluence/display/PPFFSW/FTP+Tests+for+GlobalStar+Modem 
-ITOS testing 

-ITOS is used for command and telemetry. Commanding, downloading, and CFDP 

(CCSDS File Delivery Protocol) tests were performed 
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Histogram of Connection Times 
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-Horizontal axis is the duration of the connection 

-Vertical axis is how many connections terminated in that interval 
-25% of all connections lasted less than five minutes 

-Median connection time was just over ten minutes 

-25% of all connections lasted longer than eighteen minutes 


Greg Limes email, 11/16/15 


Histogram of Times Modem Disconnected 
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measuring how long until we decided to initiate another call; usually 25 
minutes, but not infrequently eight or nine minutes. This graph does not tell 
us what the next state is, but | *think* it should usually be the "calling" state. 
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Ratio-Cumulative Con/Dis Time on (roughly) one-day Blocks 


what fraction of the time we spent connected and what 
fraction we spent disconnected, which aside from the week 
where we had no data and the last day, we are 
disconnected 10% to 12% of the time. 


Ratio Con/Dis Time 
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Cumulative Con/Dis Time on (roughly) 24 Hour Blocks 
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similar to the above, but shows the data as "accumulated 
hours" -- this exposes the ragged top due to the fact that 
the total duration of each connection is being accumulated 
into the bar that contains the start of the connection. 
Shows that we accumulated about two hours per day of 
not being connected 
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